home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92nov / vcrout-minutes-92nov.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  169 lines

  1. Editor's Note: Minutes received 12/1/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Marco E. Sosa/Bellcore
  7.  
  8. Minutes of the Virtual Circuit Routing BOF (VCROUT)
  9.  
  10. The meeting was organized as a BOF to determine if there was enough
  11. interest in forming an IETF working group to develop a standard routing
  12. algorithm for choosing paths for virtual connection set-up in a Frame
  13. Relay or ATM network.  The meeting was attended by more than 48 people.
  14.  
  15. The meeting was a presentation led by Rob Coltun covering the issues
  16. discussed at a previous meeting.  Audience feedback/discussion on the
  17. scope of issues addressed was encouraged and received.  (So much so that
  18. we didn't even get through the summary of the previous meeting's
  19. outcomes.)  The talk included:
  20.  
  21.  
  22.    o Scope of the proposed working group.
  23.    o Initial set of issues/plan of attack discussed at previous meeting.
  24.  
  25.  
  26. In addition, Juha Heinanen presented his proposal for integrated routing
  27. using NSAP addressing.
  28.  
  29. After much discussion the Group decided that there was enough interest
  30. that a IETF working group should be formed.
  31.  
  32. A mailing list has already been set up at vc-routing@gated.cornell.edu.
  33. Please use vc-routing-request@gated.cornell.edu to join.
  34.  
  35. The following topics were addressed:
  36.  
  37.  
  38.    o Rob and Marco Sosa (Bellcore) will co-Chair the Working Group and
  39.      edit the resulting specification (standards-track RFC?).
  40.  
  41.    o Rob and Marco will co-author an (informational) Internet-Draft,
  42.      before the next IETF, which will outline the envisioned scope and
  43.      architecture for which the resulting specification will apply,
  44.      including what we think are the major issues to resolve.  This will
  45.      incorporate any input received from the mailing list.
  46.  
  47.    o The resulting specification should be based on existing standards/
  48.      implementation agreements.  OSPF/RMP is one of the starting points
  49.      for our proposal (RMP is an OSPF-based protocol used in
  50.      multi-switch SMDS networks).
  51.  
  52.    o The work of this Group should not duplicate the work that is being
  53.      done in other standard groups/forums.
  54.  
  55.    o The initial focus of the Group should be within a single routing
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      domain (Autonomous System) with up to 1000 switches.  Inter-domain
  64.      routing issues will also be looked into, possibly based on IDRP.
  65.  
  66.    o We will specify the routing protocol used between switches in the
  67.      routing domain.  A switch may in fact be distributed, running
  68.      proprietary protocols internally.
  69.  
  70.    o What address resolution is performed by attached end-systems (and
  71.      how), is a hot topic that can not be decided by this Group.
  72.      However, it may be appropriate to specify a means of resolving the
  73.      addresses received within a call set-up message into a network
  74.      internal switch/ port identifier to be used by the routing
  75.      protocol.
  76.  
  77.    o Q.933 (FR)/Q.93B (ATM) signaling will be base for virtual circuit
  78.      management work.  The Group will look into extending these as
  79.      needed to define an inter-switch call set-up protocol (algorithm
  80.      and format) that will include an option for inter-domain and
  81.      inter-domain (loose) source route call set-up.
  82.  
  83.    o Alternative methods for the format of the switch identifiers were
  84.      discussed.  Using a private 32-bit address (which could be an IP
  85.      address) to ID a switch or using variable-length public NSAPs to
  86.      identify end stations attached to a switch and routing based on
  87.      these were the two main options.
  88.  
  89.    o Assignment of link metrics was discussed.  There seemed to be
  90.      agreement that metrics should be settable through administration.
  91.      There is also a proposal to define default metrics to provide a
  92.      consistent metric all switches could handle (as metrics may change
  93.      dynamically).  The proposal is to look into using the SMDS RMP
  94.      default metrics as the base.  Modifications are needed to base the
  95.      metric on ``unreserved effective BW'' rather than capacity.
  96.      Effective BW allows for over-reservation of links and leaves open
  97.      possibility of a better traffic descriptor than peak rate or CIR.
  98.      Also, ``damping'' procedures will be needed to make sure excessive
  99.      LSAs are not sent (don't want new LSA every time a new connection
  100.      is reserved over a link).
  101.  
  102.    o Three different classes of service were discussed, VC, Datagram,
  103.      and ``Soft VC'' (like VC but without strict QOS guarantees,
  104.      possibly allowing simpler call rerouting).
  105.  
  106.  
  107. The co-Chairs will create a draft Charter based on the agreements of the
  108. two meetings.
  109.  
  110. Attendees
  111.  
  112. Cynthia Bagwell          cbagwell@gateway.mitre.org
  113. Fred Baker               fbaker@acc.com
  114. Ken Benstead             kbenstead@coral.com
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Lou Berger               lberger@bbn.com
  123. Shiraz Bhanji            bhanji@gateway.mitre.org
  124. Edo Biagioni             esb@fore.com
  125. Ken Carlberg             Carlberg@cseic.saic.com
  126. Kay Chang                chang@chang.austin.ibm.com
  127. Dilip Chatwani           dilip@synoptics.com
  128. Dean Cheng               dean@sun2.retix.com
  129. Chi Chong                cchong@synoptics.com
  130. George Clapp             clapp@ameris.center.il.ameritech.com
  131. Robert Cole              rgc@qsun.att.com
  132. Osmund de Souza          osmund.desouza@att.com
  133. Art Dertke               dertke@gateway.mitre.org
  134. Jacques Dugast           dugast@issy.cnet.fr
  135. Robert Enger             enger@reston.ans.net
  136. Mike Goguen              goguen@src.dec.com
  137. Patrick Hanel            hanel@yoyodyne.dco.ntc.nokia.com
  138. Ken Hayward              crm57d@bnr.ca
  139. Frank Heath              heath@cmc.com
  140. David Husak              dave@synnet.com
  141. David Jacobson           dnjake@vnet.ibm.com
  142. Merike Kaeo              merike@alw.nih.gov
  143. George Kajos             kajos@coral.com
  144. Fong-Ching Liaw          fong@eng.sun.com
  145. Olli-Pekka Lintula       olli-pekka.lintula@ntc.nokia.com
  146. Robin Littlefield        rlittlef@wellfleet.com
  147. Andrew Malis             malis@bbn.com
  148. Tracy Mallory            tracym@3com.com
  149. Robert Moose             rmoose@gateway.mitre.org
  150. Julianne Myers           jmyers@network.com
  151. Erik Nordmark            nordmark@eng.sun.com
  152. Bala Rajagopalan         braja@qsun.att.com
  153. Jim Scott                scott@kali.enet.dec.com
  154. Frank Solensky           solensky@andr.ub.com
  155. Marco Sosa               mxs@sabre.bellcore.com
  156. Brad Steinka             brad@microcom.com
  157. Terrance Sullivan        terrys@newbridge.com
  158. John Tavs                tavs@vnet.ibm.com
  159. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  160. James Watt               james@newbridge.com
  161. Luanne Waul              luanne@wwtc.timeplex.com
  162. Guy Wells                guy2@uswest.com
  163. Ian Wilson               ianw@spider.co.uk
  164. Liang Wu                 ltw99@bellcore.com
  165.  
  166.  
  167.  
  168.                                    3
  169.